1. Field of the Invention
This invention generally relates to redundant data storage devices in a data processing network and more particularly to a method and apparatus that enables data to cascade through multiple redundant data storage units.
2. Description of Related Art
The maintenance of data integrity by data redundancy has become a very important issue. Data redundancy has several forms or variations. At a single site, mirroring or RAID redundancy protects against disk or other storage failure. In another form described in U.S. Pat. No. 6,092,066 and others, redundancy is achieved by duplicating a local system at a remote location. The use of a remote location prevents data loss due to natural disasters and the like at one site.
In accordance with the foregoing U.S. Pat. No. 6,092,066, all data processing activity occurs at a “local” or “production” site that contains a host system for processing data stored in a data storage facility. A geographically remote or backup site includes a data storage facility as a “redundant” facility for maintaining a restoration or recovery data set. In this system each time the host at the production site writes data to the production site data storage facility, the production data storage facility automatically writes data to the remote storage facility. In many, if not most, of these applications, writing data to the remote site data storage facility requires a transfer across a high bandwidth communications link so the backup procedure does not affect operations at the production facility. T3 and ESCON lines are typically preferred as the communications links despite their expense.
U.S. Pat. No. 6,101,497 discloses another concept involving a BCV device typically used at the production site. In this approach a data set, for example a “logical volume”, on a production site data storage facility, i.e., a “production volume”, operates in a normal fashion. Another logical volume at this same site is designated as a “BCV volume”. An ESTABLISH command connects the BCV volume to the production volume so that the BCV volume synchronizes with the production volume. A SPLIT command thereafter can separate the BCV volume from the production volume making the data stored on the BCV volume available for another application.
This other application may alter the data stored on the BCV volume. Consequently whenever the BCV volume is reconnected with the production volume, it is necessary to transfer data to the BCV volume that represent changes in both the BCV volume and the production volume. An alternative is to reconnect the BCV volume to the production volume by issuing another ESTABLISH command. However, this command will replace all the data on the BCV volume so all the data from the production volume must be transferred to the BCV volume whether or not changes have occurred.
In the past locating data storage facilities at a production site and a single remote site has been acceptable. In certain critical applications it is now also desirable, and in some situations mandatory, to store still another restoration copy at a third site that is remote from the first two sites. This requires some approach for copying the data from the production site to both remote sites, all transparently to the operations at the production site. Merely repeating the foregoing approach for copying data from a production site to a single remote site involves excessive communications costs. A second high-speed communications link will be required between either the production site and the second remote site or between the first and second remote sites. What is needed is a way to establish a redundant data copy over a less costly communications link without any significant disparity in the data that exists at various remotely located sites such that all the data storage facilities are in synchronism or nearly in synchronism.